Case 5;12-cv-01894-BLF Document 193-8 Filed 01/24/19 Page 1 of 15 


EXHIBIT M 


Case 5;12-cv-01894-BLF Document 193-8 Filed 01/24/19 Page 2 of 15 


From; 

Sent: 

To: 

Subject: 


Tara Stewart 

Friday, December 02, 2011 12:51 AM 
Tara Stewart 

Re: Jtasks] #578748: Bootcamp Project, Part 2: Transaction Level Data [risk-ops] 
[riskproject] [risk credits projects] 


Bennett Woo - at 2:59pm yesterday 
* changed the subscribers. Added: Bennett Woo. 

[ To see this task, go to: http://our.intern.faceboQk.com/intern/tasks/?t=578748 ] 

Tara Stewart - at 4:47pm 

Already posted this on the MC IE discussion, but posting the relevant data here too: 

Regarding the First-6 Inflow Response: 

Just ran the data for my friendly fraud inflow project This rule targeted users under the age of 17 and above the age of 
90 who were trying to spend greater than or eaual to $75 in a single txn in Pet Society, Backyard Monsters, or EA 
SPORTS FIFA Superstars: Real football & soccer!. The rule response was the first-6 CC inflow. I included refunds and 
chargebacks in the same loss bucket because together they constitute total friendly fraud. This rule was active from 
8/2/2011 to 10/31/2011. 

Users who passed inflow and made subsequent txns in any of the 3 test apps: 


13.3% of the count of txns were charged back or refunded 27.8% of the sum total of txns were lost as a result of 
chargebacks -r refunds 14.9% of these users (count) charged back or were refunded 

Users in the control group for this rule: 

19.2% of the count txns were charged back or refunded 39.9% of the sum total of txns were tost as a result of 
chargebacks + refunds 13.2% of these users (count) charged back or were refunded 

Users who passed inflow and didntt spend in the 3 test apps or users who failed inflow; 

From a statistically significant sample, 6% of these users charged back or were refunded. 32% of users in the Inflow 
group fall into this segment. 

The results from my project indicate that first-6 inflow slightly altered the chargeback and refund rates. While a smaller 
percentage of the control group users charged back or were refunded, they charged back a greater number of 
transactions and a larger total sum. Fewer transactions were uitimiately charged back or refunded from the users who 
passed inflow. Though the inflow didn't make a huge dent in the loss rate, it blocked a fair amount of users from 
purchasing in the test apps. If this were run at a larger scale, it could decrease the denominator of the segment we are 
targeting. 

Anecdotally, many of the minors who did not spend in the test apps after inflow went on to spend in other apps. 
Unfortunately, due to time constraints, 1 didn't have time to dig deeper into the users who passed inflow but didn't 
spend or all-out failed the inflow. This could be a next step. 
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Ultimately, I would recommend a first-6 inflow to the lower threshold users. 


Title: Bootcamp Project, Part 2: Transaction Level Data 
Created: 8:48am May 27th, 2011 by Tara Stewart 
Tags: risk-ops, riskproject, risk credits projects 
Priority: low-pri 
Assigned to; Tara Stewart 

Related to this original discussion on underage users: 

http://www.intern.facebook.eom/intern/discussions/#l/intern/discussions/index.php/BQot_Camp_Project__The__Financ 

ial_lmpact_of_Permitting_Minors_to_Spend_Facebook_Credits/?fbid=123396701073369 

Now focusing exclusively on users tagged with one of the three minor tags in CRT to determine if we should be 
refunding after a certain spend threshold during review 

Next steps: 

1. Sort the users in the original query by tagID 2. Determine the size of each of the samples (# of AIDs) and record the 
median CB amt per account, median refund amount, and median successful amount 3. Repeat steps 1+2 with the 
second query to get an idea of the total population of minor’s spending credits...break this query out by age: 13-17 4. 
instead of summing by AID, run a third query that pulls all transactions individually to determine the typical number of 
ebs per account and the actual impact on compliance 

To see this task, go to: http://our.intern.facebook.com/intern/tasks/?t=578748 

Reply to post a comment. 


Full History 


Tara Stewart - at 8;48am on May 27th 
created the task. 


Tara Stewart - at 8:48am on May 27th 

* changed the title to "Bootcamp Project, Part 2: Transaction Level Data" 


Tara Stewart - at 8:48am on May 27th 

* changed the description to "Related to this original discussion on underage users: 

http://www.intern.f3cebook.com/intern/discussions/#!/intern/discussions/index,php/Boot_Camp_Project__The_Financ 

iaiJmpact_of_Permitting_Minors_to_Spend_Facebook_Credits/?fbid=123396701073369 

Now focusing exclusively on users tagged with one of the three minor tags in CRT to determine if we should be 
refunding after a certain spend threshold during review 

Next steps: 

1. Sort the users in the original query by tagID 2. Determine the size of each of the samples (# of AIDs) and record the 
median CB amt per account, median refund amount, and median successful amount 3. Repeat steps 1+2 with the 
second query to get an idea of the total population of minor's spending credits...break this query out by age: 13-17 4. 
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Instead of summing by AID, run a third query that pulls all transactions individually to determine the typical number of 
cbs per account and the actual impact on compliance" 


Tara Stewart - at 8:48am on May 27th 

* changed the subscribers. Added: Tara Stewart, David Clune, Ross Worden, 


Tara Stewart - at 8:48am on May 27th 
* claimed the task. 


Tara Stewart - at 8:4Sam on May 27th 
* added the attachment "MOREFUNWlTHHIPAL2.xisx". 


Tara Stewart - at 8:48am on May 27th 
* changed the tags. Added; Tiskproject', 'risk-ops', 'credits'. 


Tare Stewart - at a:48am on May 27th 
* added the attachment "FUNWiTHHIPALxIsx". 


Tara Stewart - at 8:48am on May 27th 
* added the attachment "bootcamppart2work.xlsx". 


Tara Stewart - at 12:01pm on May 31st 

FYI...project has been slightly delayed as we work on de-bugging the third query (step 4) which will determine the actual 
impact on compliance 


Tara Stewart - at 1:50pm on June 6th 

Ran the third query and it returned 8 billion lines...needless to say, some more debugging is in order. 


Ross Worden - at 1:55pm on June 6th 

CREATE TABLE tarastew__project_bootcamp_extended_partl 

TBLPROPERTIES( RETENTION = 0','WEEKLY_GROWTH_RATE'='0') AS SELECT DISTINCT v,source_account id, v.amtsucc, 
v.amtref, v.amtcb, v.orderid 

FROM( 

SELECT a.source^accountjd as source_accountJd, 3.c_referencejd as orderid, x.amtsucc as amtsucc, c.amtref as 
amtref, e.amtcb as amtcb FROM cn_risk_ultioss_alltxns_p a 

LEFT OUTER JOIN 

( 

SELECT z.source_account_id, z.c_referencejd, z.amount_usd as amtsucc 
FROM cn_risk_uitloss_alltxns_p z 


3 


CONFIDENTIAL 


FB-IB-0001377 


Case 5;12-cv-01894-BLF Document 193-8 Filed 01/24/19 Page 5 of 15 


WHERE z.product_name == 'credits' and z.ds='2011-04-25' AND z.created_date>='2010-10-12' AND 
z.created_date<= 2011-01-12' AND ((z.refund_amt=0 AND z.cb_amount = 0) OR (z.refund_amt IS NULL AND 
z.cb_amount IS 
NULL)) 

)i< 

ON a.source_accountJd = x,source_accountJd 

LEFT OUTER JOIN 

{ 

SELECT b.source_accountjd, b.c_reference_id, b.3mount_usd as amtref FROM cn_risk_ultloss_alltxns_p b WHERE 
b.created_date__refund>='2010-10-14' AND b.ds='2011-04-25' AND b.product_name= 'credits' AND 
(b.refund_amt>0 OR b.refund_3mt IS NOT NULL) 

) c 

ON a.source_account_id = c.source_account_id 

LEFT OUTER JOIN 

( 

SELECT d.source_accountjd, d.c_reference_id, d.amount_usd as amtcb FROM cn_risk_ultloss_alltxns_p d WHERE 
d.cb_date>='2010-10-14' AND d,ds-'2011-04-25’ AND d.product_name='credits' AND (d.cb_amount>0 OR d cb amount 
IS NOT NULL) 

) e 

ON a.source_accountJd = e.source_accountJd 

WHERE a.product_name = 'credits' and a.ds='2011-04-25' AND a.created_date>='2010-10-12' AND 
a.created_date<='2011-01-12*)v; 


Ross Worden - at l;55pm on June 6th 

CREATE TABLE tarastew_project_bootcamp_extended_part2 TBLPROPERTIES('RETENTION’='30‘, 
'WEEKLY_GROWTH_RATE'='0') AS 

SELECT a.’^, g.age, CASE WHEN 

q.tagid= 131902480193255 OR q.tagid = 144022365627990 OR q.tagid =112900575408907 THEN 1 ELSE 0 END AS 
tagged 

FROM 

tarastew_projed:_bootcamp_extended_partl a 

LEFT OUTER JOIN pb_user_account f ON 
a.source_account_id=f.account_id 

LEFT OUTER JOIN dim^alLusersJnfo g ON f.user_id=g.userid AND g.ds='2011-05-01' AND g.age<=17 AND g age IS NOT 
NULL 

LEFT OUTER JOIN 

(SELECT y.objectid as objectid, y.tagid as tagid FROM object_to_tag_assoc y WHERE ds>='2010-10-12' 

ON q.objectid=f.userJd; 


Ross Worden - at l;56pm on June 6th 

;'m pretty sure the dupping is due to joining on account ids and nottxn ids in the first query 
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Tara Stewart ~ at 7:53am on June Sth 

Joined on txn id in the first query, but this still returned a huge amount of rows... 


Ross Worden - at 8:10am on June Sth 
what # of rows? 


Ross Worden - at S:12am on June Sth 

without joining on txn_id (instead, join on aid) the count is 173,640,493, I'm almost certain that the Irmany component 
of acct:txn and the join structure is responsible for dupping 


Ross Worden - at 8:14am on June 8th 
also, update the second query to: 

CREATE TABLE tarastew_project_bootcamp_extended_part2 TBLPROPERTIES{’RETENTiOIM'='30', 
'WEEKLY_GROWTH_RATE'=’0') AS 

SELECT a.*, g.age, CASE WHEN 

q.tagid= 131902480193255 OR q.tagid = 144022365627990 OR q.tagid =112900575408907 THEN 1 ELSE 0 END AS 
tagged, q.tagdate as tagdate 

FROM 

tarastew_project_bootcamp_extended_partl a 

LEFT OUTER JOIN pb_user_account f ON 
a.source_account_id=f.3ccount_id 

LEFT OUTER JOIN dim_all_usersJnfo g ON f.user_id=g.userid AND g,ds='2011-05-01' AND g.age<=17 AND g.age IS NOT 
NULL 

LEFT OUTER JOIN 

(SELECT y.objectid as objectid, y.tagid as tagid, min(ds) as tagdate FROM object_to_tag_assoc y WHERE ds>='2010-10- 
12 ' 

) q 

ON q.objectid=f.user_id; 
that m!n{ds) is going to help too 


Tara Stewart - at 8:21am on June Sth 

Joining on transaction returned 16,338,159 rows...so definitely a lot smaller than your original pull. Just not sure how to 
make this manageable since I can't even export that many rows to Excel. I'll think on it... 


Ross Worden - at 8:32am on June Sth 

I think that # makes sense given the query parameters, can you post the query # or the code so i can integrate it? We 
won't have to export to excel - you can run queries on the new table to get the txn level info, or just randomly sample 
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Tara Stewart - at 9;17am on June 8th 

Query number: 413S50. Table name: boQtcampjoinontxn 


Tara Stewart - at 5:25pm on June 17th 
* changed the tags. Removed: 'credits'. 


Tara Stewart - at 5;25pm on June 17th 
* changed the tags. Added: 'risk credits projects'. 


Tara Stewart - at 1:09pm on July 8th 

The increased concerns about cb rates from devs reminded me of the second part of this project. If the devs are really 
more concerned about cbs and not refunds it could make sense to start refunding for blatant FF-minor. Ross and I wifi 
have to revisit this data when he has time! 


Tara Stewart - at 8:45am on July 11th 
changed the subscribers. Added: Joseph Filip. 


Ross Worden - at 3;21pm on July 13th 

This should work (running in hipal2_447118) and you can add in whatever else you want to the top SELECT clause from 
riskJson_buy,,,: 


SELECT q.objectid_x as uid, q.tagid_x as tagid, q.tagdate_x as tagdate, getjson_object(a.features, ’S.RefAppId') as 
appid, u.name as appname, a.order_id, a.amountjbcents as amountjbcents, (CASE WHEN a.refundjime > 0 OR 
a.chargeback_time > OTHEN 1 ELSE 0 END) as fraud, getJson_object(a.features, '$.UserAge') as UserAge 

FROM 

( 

SELECT x.objectid_y as objectid_x, x.tagid_y as tagid_x, min(x.ds_y) as tagdate_x FROM ( SELECT y.objectid as obiectid_y, 
y.tagid as tagid_y, y.ds as ds_y FROM object_to_tag_assoc y WHERE y.ds>='2010-10-12' AND y.tagid IN 
(131902480193255,144022365627990,112900575408907) 

}x 

GROUP BY x.objectid_y,x.tagid_y 

)q 


LEFT OUTER JOIN riskJson_buy_transactians_completed a ON q.objectid_x = getJson_object(a.features, 'S.Sourceld') 
AND a.ds = '2011-07-11' AND (to_date{from_unixtime(a.transaction_ttme)) >='2010-10-12') AND 
(tD_date(from_unixtime(a.transaction_time)) <='2011-01-12') 

LEFT OUTER JOIN pb_launched_app5 u ON getJson_object(a.features, 'S.RefAppld')=u.appJd; 


Tara Stewart - at 9:54pm on July 13tb 

That data is pretty sweet. I like that you just plugged it in at the app level. It is definitely different than the data set we 
were originally looking at, but I'm ok with that I'll make some pivot charts tomorrow. 
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Tara Stewart - at 4:07pm on July 14th 
* added an attachment that was later deleted. 


Tara Stewart - at 4:08pm on July 14th 

Underagedatapplevel is fun to play around with if you are interested in app-level losses per user. 


Tara Stewart - at ll;30am on July ISth 
* added the attachment "underagedataapplevel{l).xlsx". 


Tara Stewart - at ll;35am on July 18th 

Fixed the data in underagedataapplevel. You can now research the following: 

1. Total loss and good spend in FBZ per Underage Tag per App 2. Total loss and good spend in FBZ per UID per App 

The data set includes transactions that occurred between 10/12 and 1/12 from users that were tagged with one of the 
three minor tags. The app environment has changed a bit since then (with some different apps arising as most popular 
with the under-lS set). We could use the numbers in this report to determine if we should start refunding for specific 
apps in CRT at a certain threshold. I'm open to suggestions on the best way to utilize this data. 


Tara Stewart - at 2:58pm on July 20th 

I was talking with Joseph and Dave yesterday about how we should use this data to choose apps that would be good 
recipients for an automatic underage inflow. Lossy FF-minor heavy apps that come to mind: PetVilie, Happy Aquarium, 
Wild Ones, Barn Buddy, and any Ninja game. 

We can check out a rule catered to users under the age of 18 and over the age of 100 playing these games to guess how 
many transactions this would impact. I'm for putting underage users into this inflow that are trying to purchase more 
than $75 in a single transaction or who are spending at smaller levels with a high frequency. We'll see what the data 
shows... 


Tara Stewart - at 2:57pm on July 22nd 
Backtested a rule with the following conditions: 

WHERE 

(d.ds='2011-07-19') AND 

(to_date(from_unixtime(d,transaction_time)) >='2011-06-01') AND ({getjson_object(d.features, 

'S.UserAge') <= 17) OR (getJson_object(d.features, 

'S.UserAge') >= 90)) AND 

(getJson__object(d.features, 'S.AmountReceiving') >= 

75000) 

AND 

{(g2tJson_object(d.features, 

'$.AccountBuyCredits_count_payPal_30d ') >0) OR (getJson_object(d.features, '$.CreditsBaiance') <= 0) OR 
(getJson_object(d.features, AccountsuyCredits_count_creditCard_30d') > 0)) GROUP BY getJson__^ofaiect(d.feature,?, 

'S.AppId') 
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Since the date range was only 6/1 to 7/19, the "false positives" aka spendy kids, aren't necessarily valid. I'm betting 
most of the spend for this age range will be charged back. We can use these conditions to inflow for specific FF-heavy 
apps. I tested with PetVille, and this rule looks BOMB. 


Tara Stewart - at 3:31pm on July 22nd 

Ok, after consulting with Josh, we ve determined that it makes the most sense for novi/ to focus on the Buy Credits-CC 
context. CC_VERIFY_FIRST6 was not designed to work in Spend. The only actions you can use in Spend are too drastic 
for potential FFminor cases: Block, Verify Compromised, DPO, Disable, Blacklist. The downside is that we have no 
appropriate action right now to take if a child is using his parent's PayPal account. I'm going to test again for PetVille in 
the Buy-Credits CC context for the last week only to see the kind of results we could get. This is a good first step. 


Tara Stewart - at l;27pm on July 26th 
* added the attachment "underagebacktestjulylto24.xlsx". 


Tara Stewart - at 1:40pm on July 26th 

underbacktestjulvlto24 shows the results for VI of the CC inflow rule for the buy credits-cc context. Keep in mind that 
this is unlike traditional fraud-based rules in that we don't take action on underage spend until after the fact (we don't 
know it is fraud until a cb occurs or a refund is issued). Based on these numbers (we needed a large enough sample 
size) combined with corework insights, vl is going to run on the following apps; 

1. Pet Society (11609831134); popular app for minors that already has fraud-specific rules pushed for it...we can see 
how this underage inflow will supplement the rules already in place to drive down the cb rate 

2. Backyard Monsters (342684208824): "green" app in that we haven't pushed any specific rules for it..huge minor 
population 


3, EA SPORTS FIFA Superstars: Real football & soccer! (113719625324737): another "green" app with a large minor 
population 

For v2; I'm going to look at apps that we know are FF-heavy but didn't have a high enough sample size (PetVille, Monster 
Galaxy, Ninja Saga). I'm going to pull cbs and refunds that were labeled as FF-minorto check out the characteristics of 
those accounts. 

Some ideas for looking forward; We need to determine an appropriate response for PayPal users. Maybe auto-actioning 
on users, regardless of app, once they are tagged with suspecttooyoung.” Monitoring and modifying the vl apps. 
Adopting a lower spend limit for all underage users. 


Tara Stewart - at l;41pm on July 26th 
* assigned the task to Ross Worden. 


Tara Stewart - at l;41pm on July 26th 
* changed the priority to "hi-pri". 


Ross Worden - at 8:25pm on July 26th 
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(UserAge <= 17 | ( UserAge >::: 90) && 

AmountReceiving >= 75000 
&& 

( 

AccountBuyCredits_count_payPal_30d > 0 11 CreditsBalance <= 0 11 AccountBuvCredits_count_creditCard_30d > 0 

&& 

( 

RefAppId == 11609831134 11 
RefAppId == 342684208824 11 
RefAppId == 113719625324737 


thoughts? 


Tara Stewart - at 7:08am on July 27th 
Looks good, Ross! 


Ross Worden - at 9:59am on July 27th 

Arwa Husain, can you push this in buy_cc with verifyfirstS? 


Ross Worden - at 9:59am on July 27th 
* changed the subscribers. Added: Arwa Husain, 


Ross Worden - at 9:59am on July 27th 
* assigned the task to Arwa Husain. 


Arwa Husain - at 6:31pm on July 27th 

UnderAgeInflowVl is throwing VerifyfirstS at users and control group is queuing to hipri 


Arwa Husain - at 6:31pm on July 27th 
* assigned the task to Tara Stewart. 


Josh Krivoshein - at 9:53pm on July 2Sth I'm not sure that the VERIFY_CC_FiRSTSIX response is actually an effective 
deterrent to FF...if we don't see cb reduction, it may not be the targeting of the rule. 


Note that a new order id is generated upon completion of the inflow, so figuring out which order ids we threw inflow at 
that still received cbs is tricky. I'll see if the VERIFY_CC_F!RSTSIX inflow will be included in the nexus metrics that Yihua is 
working on (it may just be the compromised inflow he's looking at). 


Joseph Filip - at 7:44am on July 29th 

Isn't the whole point of first 6 inflow to combat FFMinor? 
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April Wharton - at 7:48am on July 29th 
* changed the subscribers. Added: April Wharton. 


Tara Stewart - at 7:50am on July 29th 

Josh Krivoshein, VerifY_CC_FirstSix obviously isn't the most ideal deterrent but could be a good first step. It forces the 
minor to prove he is in possession of the credit card. Often refunds/cbs occur because a parent permits his child to 
spend at a small denomination and doesn't realize that the cc info will be stored. Obviously some kids will be able to 
grab the CC again or write the info down, but this will hopefully curb the spending of the least savvy minors. 

I hadn t been planning on looking at the specific order ids that were inflowed, but rather the overall spending of the 
LJIDs that are flagged, I'm definitely open to suggestions! 


Tara Stewart - at 8:12am on July 29th 

Also, Arwa Husain, when we grepped this rule today it didn't hit anything. Could you check the syntax? Should be in the 
buy credits-cc context and look something like this: (UserAge <= 17 11 UserAge >= 90) && AmountReceiving >= 75000 
&& ( RefAppId == 11609831134 | | RefAppId == 342684208824 | | RefAppId == 113719625324737 


I think the problem might be because I first tested this rule in the spend context and had the logic to remove app2user 
purchasers. If we kept this logic in (which we probably did), it might be messing things up. 


Ryan Kelly - at 8:25am on July 29th 
* changed the subscribers. Added: Ryan Kelly. 


Josh Krivoshein - at 12;06pm on July 29th Joseph Filip the whole point of first 6 inflow is to combat FFMinor, but I, 
wouldn't make the assumption that it is actually effective at doing this. Hopefully, analysis of the rules created by this 
task should help confirm this or not. 

The response was created about 9 months ago, when FF was a big issue. Since that time, it has become less of an issue, 
but this could be due to other factors (people became more used to credits after ail head devs were onboarded, and we 
now process a lot more volume which drowns out the FF in terms of cb compliance) rather than the impact of the first 6 
inflow response which is on very few rules. 


I checked with Yihua, the inflow metrics are in the nexus dev tier and will be pushed to prod soon. They do include 
metrics regarding VerifyCCFirste, however they are currently measuring compromised activity that occurs post inflow. I'll 
work with Yihua to change this to measure FF that occurs after this inflow. 


Josh Krivoshein - at 12:10pm on July 29th 
* added the attachment "card verification inflow stats.png" 


Joseph Filip - at 1:00pm on July 29th 

Josh Krivoshein that is a prim,ary reason we are running this. It will let us know weather this approach even works, and if 

first 6 inflow is the right/effective tool to get the job done! 

This won't be great at stopping FFAdult or buyer regret but it should keep kids from running rampant with their parents 
CC's which is a problem in certain apps. 


10 


CONFIDENTIAL 


FB-IB-0001384 


Case 5:12-cv-01894-BLF Document 193-8 Filed 01/24/19 Page 12 of 15 


Tara Stewart - at 3;21pm on August 1st 

We're going to have to recheck the syntax since this rule still hasn't hit any UiDs. Ran the backtesting query from 7/28 
to 7/30 and it should have hit 11 UIDs in EA Sports, 6 in Backyard Monsters, and 5 in Pet Society. 


Query 467940 (underagebacktestjuiy28tojuiy30) 


Tara Stewart - at 3:21pm on August 1st 
* assigned the task to Arwa Husain. 


Ross Worden - at 7:07am on August 2nd 

grep'ing shows 23 tags on seer_UnderAgelnfiowVl since 2am this morning (7 hours elapsed) 


Arwa Husain - at 8:31am on August 2nd 
* assigned the task to Tara Stewart. 


Tara Stewart - at 9:03am on August 2nd 

just perused the first sample of accounts that hit this rule. Looked at IS tags, of which 10 were unique, perhaps showing 
that minors are more likely to attempt to make rapid, high-cost purchases in a row. The inflow did work to stop some 
purchases (ie 1311307878). Other minors passed the inflow. Only one user in this group was over 18 (he listed his age 
as 106 and was playing Backyard Monsters). We will continue to monitor the hits to this rule to learn more about 
spending patterns. We will also look to see how total spend is affected in these apps. 


Tara Stewart - at 3;52pm on August 2nd 

Seems like most of these games with FF-minor problems are defaulting to the highest-cost setting in the purchase flows. 
This only exacerbates the problem since it doesn't necessarily look like "real" money to a minor. I'm going to pull some 
data for FF-heavy apps to see how many default dollar transactions have already been refunded/charged back in the 
past week. We can compare this to lower, non-default amounts to see if the chargeback/refund to good percentage is 
higher for the default setting. If so, we can recommend that they default to a lower dollar amount. 


Tara Stewart - at 9:04am on August 4th 
* changed the subscribers. Added: Doug Fraser. 


Tara Stewart - at 9:07am on August 4th 
Action Items from meeting on 8/4; 

1. Tara- continue FF minor analysis; inflow study; minor spend limit analysis 2. April - FF adult analysis, chargeback- 
specific 3. Doug - User confusion analysis, refund-specific; root-cause analysis 4. Joseph - SMS messaging; FF minor 


Meeting up in a week to talk about results. 


Tara Stewart - at S;31am on August 16th 
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I've been neglecting this task and focusing on lossy app rehab for the past week. However, the refund rates for our test 
apps have declined to normal levels, though we'll have to pull data to determine how much of this can be attributable to 
the new inflow process. From a quick skim of accounts that were recently hit by our VI inflow rule, it appears that while 
a significant portion can pass inflow, they typically go on to make lower denomination purchases (again this is just 
anecdotal). In the queues, the FFminor I'm seeing for these test apps typically occur on their parents' accounts or 
accounts where age>20. I'll revisit this when I return from PTO, but any pressing questions can be directed to Joseph 
Filip. 


Ayse Dibek - at 1:45am on August 25th 
* changed the subscribers. Added; Ayse Dibek. 


Tara Stewart - at 3:41pm on August 30th 

Joseph Filip, which apps do you think would be good to look at moving forward? Off the top of my head, I'm thinking Car 
Town and PetVille. 


Joseph Filip - at 5:12pm on August 30th 

Tara Stewart, these are apps that have been identified as having strong/moderate FFMinor problems contributing 
significantly to losses. 

Social Empires: https://our.intern.facebook.com/mtern/tasks/?t=658960 

Pocket God: https://our.intern.facebook.com/intern/tasks/?t=665294 

Wild Ones: https://our.intern.facebook.com/intern/tasks/?t=627002 

Mini Planet; https://our.intern.facebook.com/intern/tasks/?t=646869 

Ninja Warz: https://our.intern.facebook.com/intern/tasks/?t=686239 

Diamond Dash: https://our,intern.facebook,com/intern/tasks/?t=646898 

These would be excellent starting points as we begin to roll out this rule more broadly. 


Tara Stewart - at 9;13am on September 6th Talking with Pat and Joseph now about potentially providing suggestions to 
developers about ways to deal with FF. Since you authorize an app to access your information, and the dev can thus see 
your birth year, it could be beneficial to provide different price packages to minors. Instead of the max package of $100 
or $150, they could offer a max of $50 or something if age < 18. We'il discuss this further later on in the week. 


Tara Stewart - at 4:35pm on October 25th Hi Arwa, could you pause UnderAgeInflowVl? We should stop and analyze 
the data if this is something we want to continue to work on. Thanks! 


Tara Stewart - at 4;35pm on October 25th 
* changed the priority to "low-pri". 
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Tara Stewart - at 4:35pm on October 25th 
* assigned the task to Arwa Husain. 


Arwa Husain - at 10;34am on October 31st I have deleted UnderAgeinflowVl from sigma buy cc 


Arwa Husain - at 10;34am on October 31st 
* assigned the task to Tara Stewart. 


Bennett Woo - at 2;59pm yesterday 
* changed the subscribers. Added: Bennett Woo. 


Tara Stewart - at 4:47pm 

Already posted this on the MC IE discussion, but posting the relevant data here too; 

Regarding the First-6 Inflow Response; 

Just ran the data for rny friendly fraud inflow project. This rule targeted users under the age of 17 and above the age of 
90 who were trying to spend greater than or equal to $75 in a single txn in Pet Society, Backyard Monsters, or EA 
SPORTS FIFA Superstars: Real football & soccer!. The rule response was the first-6 CC inflow. I included refunds and 
chargebacks in the same loss bucket because together they constitute total friendly fraud. This rule was active from 
8/2/2011 to 10/31/2011. 

Users who passed inflow and made subsequent txns in any of the 3 test apps: 

13.3% of the count of txns were charged back or refunded 27.8% of the sum total of txns were lost as a result of 
chargebacks + refunds 14.9% of these users (count) charged back or were refunded 

Users in the control group for this rule: 

19.2% of the count txns were charged back or refunded 39.9% of the sum total of txns were lost as a result of 
chargebacks + refunds 13.2% of these users (count) charged back or were refunded 

Users who passed inflow and didn't spend in the 3 test apps or users who failed inflow; 

From a statistically significant sample, 6% of these users charged back or were refunded. 32% of users in the inflow- 
group fall into this segment. 

The results from my project indicate thatfirst-o inflow slightly altered the chargeback and refund rates. While a smaller 
percentage of the control group users charged back or were refunded, they charged back a greater number of 
transactions and a larger total sum. Fewer transactions were ultimately charged back or refunded from the users who 
passed inflow. Though the inflow didn't make a huge dent in the loss rate, It blocked a fair amount of users from 
purchasing in the test apps. If this were run at a larger scale, it could decrease the denominator of the segment we are 
targeting. 
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Anecdotally, many of the minors who did not spend in the test apps after inflow went on to spend in other apps. 
Unfortunately, due to time constraints, I didn't have time to dig deeper into the users who passed inflow but didn't 
spend or all-out failed the inflow. This could be a next step. 

Ultimately, I would recommend a first-6 inflow to the lower threshold users. 


To see this task, go to: http;//our.intern.facebook.com/intern/tasks/?t=578748 
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